Can you provide to me the use case so I can better understand why a generic params map is meant for?

Sure. According to the documentation each "list endpoint" supports different query params to filter the result. I.e. the list users endpoint supports the email parameter while the list bank accounts endpoint supports the type parameter. In order to find a specific user the best / most performant way to find the user would be filtering by email address which is not supported by the current implementation. Listing all users and filtering client side seems like a huge waste of resources.

We could have well defined query classes for each endpoint only exposing the supported params. If it'd be up to me only I would go with the map implementation since it allows developers to use parameters that might have been introduced to the api but are not yet included in the the query classes.

Following the design we have today, I'd prefer creating a HyperwalletUserListOptions that extends HyperwalletPaginationOptions.

I get when you say that this is way more flexible, but we want to keep our SDK self contained without requiring the developer to go check our documentation to understand what is available to be used and what isn't. That also helps us unit test it.

Fine for me. I'll pick it up.

Please check again. I'm not super happy with the current implementation but tried to prevent unnecessary changes.

My idea would be:

• introduce getParameters into HyperwalletPaginationOptions
  • to make this change happen, the date conversion needs to be moved from Hyperwallet to HyperwalletPaginationOptions
• HyperwalletUserListOptions would override getParameters, take the parent params and add its own
• paginate or addParametersin Hyperwallet could be replaced with one of the others

I did like @dfreudenberger but I will ask you to stick with the current design. We are planning to do changes on all our server SDKs to support the changes in our REST v4 and I will keep it in mind to implement for all resources.